Rebate automation

ABSTRACT

A computer receives information that a request is made to authorize a transaction for a sale of a product by a merchant to an account holder in a transaction conducted on a consumer account issued to the account holder. When the computer confirms that the transaction is authorized and that the transaction occurs within a predetermined time period for which there is a rebate associated with the product and a corresponding sponsor financially responsible for the rebate, the computer communicates that the rebate is to be debited to an account of the sponsor and either: (i) given as a discount by the merchant at the point of sale to the account holder; or (ii) credited to an account issued to the account holder by the issuer.

RELATED APPLICATIONS

The present application is a continuation application of U.S. patentapplication Ser. No. 12/784,324, filed May 20, 2010 and entitled “RebateAutomation”, which claims priority to, and the benefit of, Prov. U.S.App. Ser. No. 61/180,343, filed on May 21, 2009 and entitled “RebateAutomation,” and Prov. U.S. Pat. App. Ser. No. 61/180,363, filed on May21, 2009, titled “Rebate Automation,” the entire disclosures of whichapplications are incorporated herein by reference.

FIELD OF THE TECHNOLOGY

The present invention relates to a transaction with a merchant on anaccount held by an account holder, and more particularly relates to arebate on the transaction.

BACKGROUND

A rebate program is a common tool for delivering added-value toconsumers, and thus motivating incremental sales for a sponsor of therebate program. The sponsor is usually a manufacturer, although otherparties can individually or collectively sponsor the rebate program.Rebates typically require consumers to mail-in a purchase receipt andpossibly other items, after which they receive a rebate check or giftcard by mail. Manufacturers typically use third party service providersto handle in-bound mail receipts, verification, and production/deliveryof rebate checks or gift cards.

Rebates are typically offered across all of the manufacturer's keydistribution points such that a consumer can obtain the rebate from anyparticular merchant selling the manufacturer's products. Typicalrequirements of a standard rebate program usually involve a rebate offerpertaining to a specific product or service that can be uniquelyidentified such as by a Universal Product Code (UPC) or a stock-keepingunit (SKU). The manufacturer usually requires something physical to bereturned by the consumer to track situations where the product purchasedunder a rebate program is returned after the rebate is sent to theconsumer. For example, a consumer may be required to tear off and sendback to the manufacturer a UPC, often appearing as a bar code, onpackaging of a purchased product. The UPC will be required under therebate program in order to have the requested rebate processed and paid.

The manufacturer's economic model assumes ‘slippage’, meaning that theprocess of collecting and mailing in the required items can discourage aconsumer from responding to the rebate offer. The consumer, aftershopping for a rebate eligible product or service, may forget, or lackthe initiative, to collect all of the required rebate paperwork, fillout the required rebate forms, and properly address a mailing of theexecuted paper work to make a claim for the rebate. In fact, not allpurchasers will go through with all of the steps that are required inorder to get the rebate in a specified time frame. Also, consumers maysubmit incorrect or illegible data and nonconforming information. As aresult of this lack of rebate program compliance by consumers, asubstantial percentage of all rebates never get redeemed. As such, fewerrebates are paid by the rebate sponsors who, therefore, have anincentive to keep rebate redemption rates down by setting strict andrigorous rebate program rules. These rules may include limited filingperiods, long processing time frames, rigorous requests for personalinformation, etc. As such, even substantially completed rebate formsmight allow the corresponding rebate to be denied under rebate program'srules.

Another deterrent for consumers to participate in a rebate program isthat there can be uncertainty around the rebate process. Thisuncertainty, in some cases, is because consumers have no way to find outif their submission of a rebate claim was received, if the claim hadbeen verified for payment, or when the rebate will be paid.

For those consumers that actually do receive a rebate check or gift cardin the mail, some paper rebate checks or gift cards are tossed in thetrash by the consumer because they can be packaged in envelopes thatlook like ‘junk mail’. The consumer behavior, often referred to as“breakage”, occurs where a rebate is mailed but not redeemed or cashedby the mail recipient.

For the manufacturer or other sponsor of a rebate program, the cost ofimplementing a rebate program via physical processes (use of maildelivery services and paper rebate checks) is substantial on aper-rebate basis. The process makes it challenging to limit rebates toselect distribution points (i.e., retailers) or to vary the rebateamount by the specific retailer. The cost of rebate programimplementation also creates hurdles for partnerships betweenmanufacturers and payment brands (e.g., Visa, Master Card, AmericanExpress, etc.) on rebate offers, since the necessary data is not easilyobtained or easily used for processing rebates in the current prior artprocesses. On the other hand, retailers and manufacturers are in favorof rebates because they allow the consumer to focus, at the Point ofService terminal (POS), on paying the discounted, rebate price for aproduct or service, although the consumer is actually paying full priceat the POS.

There is a need in the art to solve the forgoing rebate programproblems.

SUMMARY OF THE DESCRIPTION

In one implementation, a computer receives information that a requesthas been made to authorize a transaction for a sale of a product by amerchant to an account holder in a transaction conducted on a consumeraccount issued to the account holder. When the computer confirms thatthe transaction is authorized and that the transaction occurs within apredetermined time period for which there is a rebate associated withthe product and a corresponding sponsor financially responsible for therebate, the computer communicates that the rebate is to be debited to anaccount of the sponsor and is to be given as a discount by the merchantto the account holder at the point of sale.

In another implementation, a registrar receives applicants to registeraccounts for participation in a rebate program. The registrar is incommunication with a transaction handler who, alone or via a third partyadministrator, administers the rebate program for applicabletransactions on the registered accounts. A sponsor of the rebateprogram, who is in communication with the transaction handler, can beany number of individual or collective entities (an issuer of aregistered account, a merchant retailing a rebate-eligible product, amanufacturer of a rebate-eligible product, a distributor of arebate-eligible brand of products, etc.) For example, an issuer of anaccount to a consumer can be a bank that participates in a rebateprogram as a sponsor of the rebate program either on its own or with aparticular manufacturer or merchant of a particular rebate-eligibleproduct or brand of products. As an added value, because registrationthrough a registrar can be required for rebate eligible accounts, anadministrator of a rebate program (e.g., such as a payment processingentity like a transaction handler) has the ability to collect and mineaccount holder data that can be licensed for use to various rebateparticipating entities, such as shopping behavior of registered accountholders.

For consumers, the process of registering one or more account numbersthrough a registrar, such as at a web portal for a web service, resolvessome of the uncertainty issues experienced in the prior art rebateprogram processes. For instance, an account holder can be offered aconvenient way to interactively participate in a rebate program withcommunications between the account holder and rebate participatingentities that inform the account holder with rebate relevant informationthrough a website accessible via web enabled stationary or mobiledevices. In one implementation, an account holder can register one ormore accounts online for which the account holder wants to receive arebate for making a purchase on their account of one or morerebate-eligible products from one or more rebate-eligible merchants. Therebate-eligible product for which the account holder registers can bemade by one or more manufacturers and be within one or morerebate-eligible brands that qualify for one or more rebate programs thatare offered to the account holder by the issuer of the account. Any suchrebate-eligible transaction on the account of the account holder will beprocessed by the transaction handler who is in communication with theregistrar. The registration process can occur in response to a notice ofa rebate program by an issuer, a merchant, a manufacturer or atransaction handler (or a combination thereof). Alternatively theconsumer can register online after making one or more rebate-eligiblepurchases on their account. An account holder, in one implementation,can take advantage of a rebate offer for an purchase made in person oronline, which rebate can be further upgraded or enhanced by theissuer-recognized level of the account upon which the transaction wasconducted (i.e., gold card, silver card, platinum card, infinite card,etc.)

In yet another implementation, transaction data captured at the Point ofSale terminal (POS) in real-time can include product level data. Thetransaction handler, upon receipt of the transaction data, storesinformation about the account holder including demographic data. Thesedata can then be shared with various sponsors of a rebate program toascertain its successful and the relative merits of future rebateprograms.

BRIEF DESCRIPTION OF THE DRAWINGS

Implementations of the invention will become more apparent from thedetailed description set forth below when taken in conjunction with thedrawings, in which like elements bear like reference numerals.

FIG. 1 illustrates a system level diagram depicting an exemplary rebateprogram among cooperating entities within a payment processing network;

FIG. 2 illustrates a report generated from information included in atransactions database for transactions conducted on correspondingregistered accounts with merchants, where each transaction was conductedon an account of an account holder for a rebate-eligible good orservice;

FIG. 3 illustrates a report generated from information included in arewards program database, where the report includes transactioninformation about each of several rebate programs;

FIG. 4 is a flow diagram illustrating an exemplary rebate redemptionprocess;

FIG. 5 depicts a system level diagram of an exemplary payment processingnetwork illustrating an environment in which the rebate programsdisclosed herein may be implemented;

FIG. 6, depicts a system level diagram of an exemplary transactionprocessing system as an environment in which the rebate programsdisclosed herein may be implemented;

FIG. 7 illustrates systems housed within an interchange center toprovide online and offline transaction processing of transactions in apayment processing system of FIG. 6; and

FIG. 8 illustrates another view of the components of FIG. 7.

DETAILED DESCRIPTION

A system for recognizing and administering a rebate, according to oneimplementation, is shown in FIG. 1. Rules are maintained in a RebateRules Database (y) 182 for each rebate program maintained in a RebatePrograms Database (x) 184. These rules are established for the use ofMerchants 110 by one or more sponsors (m) 140 of each rebate program.Each Sponsor (m) 140 will charged for, and is expected to pay, all or aportion of the rebate amount according to the rules. By way of example,each Sponsor (w) 140 can be an Issuer (j) 104, a Merchant (n) 110, amanufacturer, a wholesaler, a corporate parent of any of the foregoing,etc. Each Sponsor (m) 140, who may have a communication capability 185with each Merchant (m) 110, has an account recognized by a TransactionHandler (k) 102. The Transaction Handler (k) 102 will use the account ofthe Sponsor (m) 140 to make rebate settlements, either paying moniesinto the account for returned products for which rebates had alreadybeen paid, or for monies withdrawn for rebates to be paid and for whichthe Sponsor (m) 140 is responsible.

Issuer (j) 104 sends notification 150 to Account Holder (p) 108 of a newrebate registration program on a Registrar (w) 116 which may be, forinstance, an interactive web service. After receipt of such notification150, Account Holder (p) 108 sends a notification 152 to Issuer (j) 104of its interest in participating in the new rebate registration programand registers 118 its account information with the Registrar (w) 116 forstorage in Transactions Database (z) 180 for the particular rebateprogram in the Rebate Programs Database (x) 184 which complies with oneor more program rules maintained by the Rebate Rules Database (y) 182.Registrar (w) 116 sends notices 192, 194 of Account Holder (p) 108'sregistration to Issuer (j) 104 and to Transaction Handler (k) 102,respectively. Transaction Handler (k) 102 may, in turn, send updates163, 190 to each Sponsor (m) 140 and to (i) the Transactions Database(z) 180; (ii) the Rebate Rules Database (y) 182; and (iii) the RebatePrograms Database (x) 184.

In one implementation, Account Holder (p) 108 wishes to conduct atransaction on their account with a Merchant (n) 110 to purchase 158 agood or a service, for instance a particular brand and model of a laptopcomputer, which is eligible for a rebate. The laptop computer can besubject to a rebate offer to the Account Holder (p) 108 who can purchasethe laptop on their account for $1400.00 with a rebate of $200, wherethe offer of the rebate is made by the manufacturer seen in FIG. 1 asSponsor (m) 140. To conduct the transaction, the Account Holder (p) 108presents to Merchant (n) 110 a payment device associated with theaccount of the account holder, like a credit card, debit card, giftcard, or any other payment device that is linked to the account of theAccount Holder (p) 108.

Merchant (n) 110 transmits 162 information about the laptop to Acquirer(i) 106. This information can be product level data, often referred toas Level III data, and can include a Stock Keeping Unit (SKU), aUniversal Product Code (UPC), an identifier for the Manufacturer, aModel Number, a Serial Number, a Lot Number, an International StandardBook Number (ISBN), an identifier for a commodity into which the good orservice being purchased may be classified, etc.

The Acquirer (i) 106 in turn transfers 170 data derived from thetransaction to the Transaction Handler (k) 102 for authorization. TheTransaction Handler (k) 102 will verify eligibility of the transactionfor the rebate with components of each of (i) the Transactions Database(z) 180; (ii) the Rebate Rules Database (y) 182; and (iii) the AccountHolder (p) 108's registered account(s) in the Rebate Programs Database(x) 184. Transaction Handler (k) 102 will transmit 174 data derived fromthe transaction to the Issuer (j) 104 that issued the account to theAccount Holder (p) 108 to obtain authorization that Account Holder (p)108 has authority to make purchases on the account and that the accounthas credit available and/or a remaining balance to make the purchase ofthe laptop and any other products or services in the transaction.

In one implementation, Issuer (j) 104 authorizes 176 the transactionwith Transaction Handler (k) 102 and Transaction Handler (k) 102transmits 168 an authorization of the purchase to Acquirer (i) 106, whoin turn notifies 166 the Merchant (n) 110 of the authorization. Issuer(j) 104 reports 192 the status of the rebates received on Account Holder(p) 108's account to the Registrar (w) 116. In another implementation,Issuer (j) 104 will decline 176 the transaction with Transaction Handler(k) 102 and Transaction Handler (k) 102 will transmit 168 the lack ofauthorization of the purchase to Acquirer (i) 106, which in turnnotifies 166 the Merchant (n) 110 as to the lack of authorization.

In one implementation, the account holder may be required to pay thefull retail price of the rebate-eligible laptop 156 to the Merchant (n)110 before receiving the rebate. Thereafter, however, the rebate amountfor the laptop will be paid as a statement credit to the account of theAccount Holder (p) 108. In this implementation, Sponsor (m) 140 willauthorize 163 the rebate transaction with the Transaction Handler (k)102. Transaction Handler (k) 102 will verify the rebate transaction withthe Transactions database (z) 180, the Rebate Rules Database (y) 182 andthe Rebate Programs Database (x) 184. After this verification, theTransaction Handler (k) 102 will transmit 163 verification informationto Sponsor (m) 140. Sponsor (m) 140 will then authorize 163 TransactionHandler (k) 102 to transmit 174 a credit to the statement of account forthe Account Holder (p) 108 via the Issuer (j) 104. The statement creditwill be for the rebate amount for the laptop. Issuer (i) 194 may alsonotify 150 Account Holder (p) 108 of the credit to their statement forthe account.

In another implementation, the Account Holder (p) 108 pays 156 the fullprice less the rebate amount for the laptop 156 to the Merchant (n) 110.For instance, when authorization is obtained, Merchant (n) 110 givesAccount Holder (p) 108 the laptop 158 for a full price of $1400.00 lessa $200.00 rebate in accordance with the rules as maintained in theRebate Rules Database (y) 183. Thereafter, the Merchant (n) 110 willreceive payment of the rebate amount from each responsible Sponsor (m)140. Thus, the Merchant (n) 110 is repaid for the difference between theamount paid 158 by the Account Holder (p) 108 for the laptop and theactual price of the laptop. Here, when done in a batch mode after anumber of transactions by account holders 108 for laptops purchased froma Merchant (n) 110, the Sponsor (m) 140 will reimburse the Merchant (n)110 for the number of $200.00 rebate offers conducted over a particularperiod of time corresponding to the batch of the transactions. Sponsor(m) 140 will authorize 163 the rebate transactions with the TransactionHandler (k) 102. Transaction Handler (k) 102 will verify the rebatetransactions with the Transactions database (z) 180, the Rebate RulesDatabase (y) 182, and with the Rebate Programs Database (x) 184. Afterthis verification process, the Transaction Handler (k) 102 will transmit163 verification information to Sponsor (m) 140. Sponsor (m) 140 willthen authorize 163 Transaction Handler (k) 102 to transmit 168 a creditto Merchant (n) 110's Acquirer (i) 106 for the difference between therebate purchase price and original price on a particular mutually agreedsettlement period, e.g. monthly, quarterly or yearly. Acquirer (i) 106will notify 166 Merchant (n) 110 of the credit to the statement for theaccount of the Merchant (n) 110.

If Account Holder (p) 108 wants to review the various purchases madeover time that were eligible for rebates, Account Holder (p) 108 cancheck the status 118 of their rebates with the Registrar (w) 116.

After a rebate-eligible purchase has been made and the correspondingrebate given, the Account Holder (p) 108 can return the product. In sucha case, there will be a rebate product settlement process that will beconducted. In one implementation, for any rebate-eligible product thathad been returned by the Account Holder (p) 108, Sponsor (m) 140 canobtain a refund for any rebate payment that the Sponsor (m) 140 hadpreviously given to either the Merchant (n) 110 or to the Account Holder(p) 108.

In one implementation, where Account Holder (p) 108 had paid the fullprice for the laptop and then received a $200.00 rebate as a statementcredit, but thereafter the Account Holder (p) 108 returned the laptop toMerchant (n) 110, Merchant (n) 110 transmits 162 information about thereturned product to Acquirer (i) 106, who in turn transmits 170 dataabout the returned product to the Transaction Handler (k) 102.Transaction Handler (k) 102 evaluates the return of the product in lightof the original transaction and the rules for a corresponding rebateprogram as are maintained in (i) the Transactions Database (z) 180; (ii)the Rebate Rules Database (y) 182; and (iii) the Rebate ProgramsDatabase (x) 184. From this evaluation, Transaction Handler (k) 102facilitates 174 a negative statement credit for the rebate amount to theaccount of the Account Holder (p) 108 via the Issuer (j) 104, andfacilitates 163 a repayment of the rebate amount to the Sponsor (m) 140.

In another implementation, Account Holder (p) 108 paid $200 less thanfull price to the Merchant (n) 110 for the laptop. In this case, theMerchant (n) 110 has already been reimbursed for the $200 rebate fromthe Sponsor (m) 140. Thereafter, however, the Account Holder (p) 108returns the laptop to Merchant (n) 110. The Merchant (n) 110 transmits162 information about the returned product to Acquirer (i) 106, who inturn transmits 170 data about the returned product to the TransactionHandler (k) 102. Transaction Handler (k) 102 evaluates the return of theproduct in light of the original transaction and the rules for acorresponding rebate program as are maintained in (i) the TransactionsDatabase (z) 180; (ii) the Rebate Rules Database (y) 182; and (iii) theRebate Programs Database (x) 184. From this evaluation, TransactionHandler (k) 102 facilitates 168 a negative statement credit for therebate amount to the account of the Merchant (n) 110 via the acquirer(i) 106, and facilitates 163 a repayment of the rebate amount to theSponsor (m) 140.

In another implementation, a rebate program makes a requirement of thepurchase of multiple different products for rebate eligibility. Here,the Account Holder (p) 108 has been issued an account that is thenregistered with Registrar (w) 116. The Account Holder (p) 180 is toreceive an incentive of an offer of a rebate to conduct a transaction onthe account with Merchant (n) 110 to purchase a specific set of brandedproducts: an external monitor of Brand A, a printer of Brand B, and alaptop of Brand C. The data derived from the transaction will be storedin Transactions Database (z). According to rules maintained in a RebateRule Database (y) 182 for a Rebate Program maintained in Rebate ProgramsDatabase (x) 184, Merchant (n) 110 is authorized to offer apredetermined rebate of $350 for such a rebate-eligible transaction. Aplurality of respective sponsors 140 will be responsible for sharing thecost of giving a statement credit to the account of the Account Holder(p) 180 who conducts the transaction, and/or for reimbursing theMerchant (n) 110 who sells the predetermined set of branded products atthe rebated price. By way of example, the sponsor for the portion of therebate pertaining to external monitor of Brand A might be the corporatehead of Merchant (n) 110, the sponsor of the portion of the rebatepertaining to the printer of Brand B might be the domestic wholesaler ofthe printers, and the sponsor the portion of the rebate pertaining tothe laptop of Brand C might be the manufacturer of Brand C.

In this implementation, the Account Holder (p) 108 presents 156 toMerchant (n) 110 a payment device like a Visa credit card, debit card,gift card, or any other payment device linked to the registered accountof the Account Holder (p) 108 to purchase the predetermined set ofbranded products for which the rebate is eligible. Merchant (n) 110sends 162 data derived from the purchase to Acquirer (i) 106 which inturn transfers 170 the data to the Transaction Handler (k) 102 forauthorization. Transaction Handler (k) 102 verifies whether the rebatecan be authorized via databases 180-184. The Transaction Handler (k) 102will transmit 174 data from the transaction to the Issuer (j) 104 of theaccount of the Account holder (p) 108 to obtain authorization for thetransaction. The authorization sought by the Transaction Handler (k) 102from the Issuer (j) 104 is whether the Account Holder (p) 108 hasauthority to make purchases on the account of the payment device andthat the account has credit available or a sufficient remaining balanceto make the purchase of the predetermined set of branded goods. Such anauthorization may take into consideration that the total upfrontpurchase price may be less than normal due to a Point-of-Sale rebateavailable for the predetermined set of branded goods.

The Issuer (j) 104 authorizes 176 the transaction with TransactionHandler (k) 102 and Transaction Handler (k) 102 transmits 168authorization of the rebate-eligible transaction to Acquirer (i) 106,who in turn notifies 166 the Merchant (n) 110 of the successfulauthorization. Alternatively, Issuer (j) 104 will decline 176 thetransaction with Transaction Handler (k) 102 and Transaction Handler (k)102 transmits 168 the lack of authorization of the purchase to Acquirer(i) 106, who in turn notifies 166 the Merchant (n) 110.

Once authorization is obtained, Merchant (n) 110 gives 158 AccountHolder (p) 108 the predetermined set of branded goods. Thereafter, theabove described processes would apply, respectively, to the TransactionHandler (k) 102 facilitating the obtaining from the plurality ofrespective sponsors 140 the prorated cost of: (i) giving the statementcredit to the account of the Account Holder (p) 180 who conducts thetransaction, and (ii) reimbursing the Merchant (n) 110 who sells the setof branded products at the rebated price. Here, the prorated costretrieved from each Sponsor (m) 140 would be a function of data in thedatabases 180, 182, and/or 184.

Of course, the rebate program might have allowed the Account Holder (p)108 to purchase each of the different products from a plurality ofdifferent Merchants 110 in order to qualify for the single rebates, inwhich case the last Merchant (n) 110 may give the rebate at the POS, orthe Transaction Handler (k) 102 may facilitate a statement credit to theaccount of the Account Holder (p) 108 after the full price was paid foreach of the different products.

In yet another implementation, the Account Holder (p) 108 can return allor a part of the multiple different products for which a single rebatehad been given. Should the Account Holder (p) 108 return one or more ofthe goods in the predetermined set of branded goods, as set forth above,the rebate given would be recovered from the Account Holder (p) 108 as afunction of data in the databases 180, 182, and/or 184. The recoveredrebate might also be predetermined to be returned prorata to theplurality of respective sponsors 140 as a function of data in thedatabases 180, 182, and/or 184.

In still another implementation, data can be mined from the abovedescribed rebate transaction collection process. In particular theAccount holder (p) 108's demographic information can be used to deduceconsumer behavioral patterns. To do so, information in the Transactions(z) 182, the accounts in the Rebate Programs (x) 184, and the RebateRules Database (y) 182 can be mined for reporting and analysis. Thesedata and analysis can be provided by Transaction Handler (k) 102 to eachSponsor (m) 140 participating in a particular rebate program.

In FIG. 1, a plurality of Transaction Handlers 102 may be participatingin a rebate program. For instance, such a plurality of TransactionHandlers 102 may include Visa, Master Card, American Express, DinersClub, Discover Card, Sears, Wal-Mart, Shopko, Target, etc. In such acase, one (1) third party rebate program administrator, seen in FIG. 1at reference numeral 105, may be in communication with, and used by,each Transaction Handler (k) 102 to perform the above described rebateprogram processes.

An exemplary report 200 is seen in FIG. 2 which reports a pluralityaccounts 202 as being registered by Registrar (w) 116 to participate ina rebate program as stored in Rebate Rules Database (y) 182 and RebatePrograms Database (x) 184. A plurality of transactions 204 on report200, corresponding to a respective one of the plurality of accounts 202,are shown as having been rebate-eligible. Data pertaining to each suchtransaction 202 can be derived from Transactions Database (z) 180.

An exemplary report 300 is seen in FIG. 3 which reports on informationin Rebate Programs Database (x) 184. A plurality of Reward Programs 352are shown as well as the accounts 354 that are registered with eachprogram. Rules 356, drawn from Rebate Rules Database (y) 182, showsthose merchants 360 that are participating in the program and therespective rebate amount each is allowed to offer, as well as otherterms of the program. Sponsors 362, listed on report 300 at the column358 labeled “Reward/Payors” are listed for each Rewards Program 352.

FIG. 4 is a flow diagram illustrating an exemplary rebate redemptionprocess 400 in which, at step 402, rules are added to Rebate RulesDatabase (y) 182 for a rebate program stored in Rebate Programs Database(x) 184, and accounts are registered by Account Holders (p) 108 withRegistrar (w) 116. At step 404, a Transaction Handler (k) 102 (or thirdparty agent provider 105 thereof), receives a transaction for storing inTransactions Database (z) 180. At step 406, an attempt is made byTransaction Handler (k) 102 to match the account of the transaction withregistered accounts maintained by Registrar (w) 116. If the account ismatched, then the received transaction is analyzed against databases182-184 for matching eligibility and compliance with one or more rebateprograms. If there is no match, as determined at step 408, then anoptional notice of noncompliance can be transmitted at step 410. Ifthere is the required matches for both eligibility and compliance, thenstep 414 allows the Transaction Handler (k) 102 to identify the matchingrebate program Sponsor(s) (m) 140. When so identified, the TransactionHandler (k) 102 obtains from the respective accounts of the matchingrebate program Sponsor(s) (m) 140 the rebate amount for the qualifyingtransaction, as shown at step 416. The rebate amount so obtained canthen be paid as a statement credit, at step 418, into the account of theregistered Account Holder (p) 108 who conducted the qualifyingtransaction on their account. Alternatively, the rebate amount soobtained can be offered as a discount at the POS by the merchant whowill then be repaid, at step 418, as a credit to the merchant's accountwith their corresponding acquirer in the form of a statement credit.Optionally, the registered Account Holder (p) 108 can be messaged atstep 420 to confirm that they had won a rebate, thereby inducing loyaltyto both the rebate sponsor. Loyalty may also be induced to other partiesthat are noticeably associated with the rebate (e.g., the Issuer (j)104, the Merchant (n) 110 with whom the rebate-eligible transaction wasconducted, the Transaction Hander (k) 102 (Visa, Master Card, AmericanExpress, Diners Club, Discover Card, Sears, Wal-Mart, Shopko, Target,etc.)) who facilitated and perhaps also advertised the relationshipbetween the parties depicted in FIG. 1 and through whom the rebate wascredited to the registered account.

Following the processing of each rebate-eligible transaction at step420, the next transaction can be similarly processed by the TransactionHander (k) 102. As demonstrated, the Transaction Hander (k) 102 canbuild loyalty by providing an alternative to paper rebate checks andother rebate requirements by offering to the registered Account Holders108 the above described process that is comparably simplified for theaccount holder, thereby differentiating cooperating merchants,manufacturers, and brands from those that do not participate in thesimplified process, thereby increase sales.

In yet another implementation, a payment processing network has aplurality of transaction handlers each of which is in communication, forthe processing of payments on respective transactions, with a respectiveplurality of acquirers and a respective plurality of issuers. In thisnetwork, each transaction handler processes transactions on a set ofaccounts that is different from the set of accounts processed by anyother transaction handler. For instance, one such transaction actionhandler can be Visa, another American Express, another Discover Card,another, Diners Club, another Master Card, etc. In this implementation,a Third Party Rebate Program Administrator (TPTPA) is in communicationwith each of the transaction handlers. In this network, the TPTPAreceives information from one of the transaction handlers that there hasbeen a sale of a product by a merchant to an account holder in atransaction conducted on a consumer account issued to the accountholder. For this transaction, the consumer account was issued to theaccount holder by an issuer. The merchant communicates the transactionto an acquirer who communicates the transaction to the transactionhandler who requests payment for the transaction from the issuer and whopays the acquirer for the merchant with a payment for the transactionfrom the issuer. The acquirer then pays the payment for the transactionto the merchant. According to predetermined rules for a rebate program,the TPTPA confirms that the transaction has occurred within apredetermined time period and that there is a rebate associated with theproduct and a corresponding sponsor that is financially responsible forthe rebate.

Upon such confirmation, the TPTPA forms a transmission containinginformation for delivery to the corresponding transaction handler givinginstructions to: (i) debit the rebate to a sponsor account of thesponsor; and (ii) inform the merchant, through the correspondingacquirer, to discount the sale of the product to the account holder bythe amount of the rebate, or alternatively, to credit the rebate to theconsumer account issued to the account holder by the correspondingissuer. Note that, in some implementations, a rebate can be received bya consumer regardless of which participating account the consumer hadused to conduct the transaction.

Exemplary Transaction Processing System

As background information for the foregoing description, as will bereadily understood by persons of ordinary skill in payment systems, thetransaction in the payment system can include participation fromdifferent entities that are each a component of the payment processingsystem. An exemplary payment processing system is depicted in FIG. 5 asthe payment processing system 500. The payment processing system 500includes an issuer 504, a transaction handler 506, an acquirer 508, amerchant 510, and a consumer 502. The acquirer 508 and the issuer 504can communicate through the transaction handler 506. The merchant 510may utilize at least one POS that can communicate with the acquirer 508,the transaction handler 506, or the issuer 504. Thus, the POS is inoperative communication with the payment processing system 500.

Typically, the transaction begins with the consumer 502 presenting acorresponding account number of the account, such as through the use ofa computer terminal or a portable consumer device 512, to the merchant510 to initiate an exchange for a good or service. The consumer 502 maybe an individual or a corporate entity. The consumer 502 may be anaccount holder of the account issued by the issuer 504 such as a jointaccount holder of the account or a person having access to the accountsuch as an employee of a corporate entity having access to a corporateaccount. The portable consumer device 512 may include a payment card, agift card, a smartcard, a smart media, a payroll card, a health carecard, a wrist band, a machine readable medium containing accountinformation, a keychain device such as the SPEEDPASS® commerciallyavailable from ExxonMobil Corporation or a supermarket discount card, acellular phone, personal digital assistant, a pager, a security card, acomputer, an access card, a wireless terminal, or a transponder, forexample. The portable consumer device may include a volatile or anon-volatile memory to store information such as the account number or aname of the account holder.

The merchant 510 may use an acceptance point device, such as the POS toobtain account information, such as the indicator for the account (e.g.,the account number of the account), from the portable consumer device.The portable consumer device may interface with the POS using amechanism including any suitable electrical, magnetic, or opticalinterfacing system such as a contactless system using radio frequency, amagnetic field recognition system, or a contact system such as amagnetic stripe reader. The POS sends a transaction authorizationrequest to the issuer 504 of the portable consumer device.Alternatively, or in combination, the portable consumer device maycommunicate with the issuer 504, the transaction handler 506, or theacquirer 508.

The issuer 504 may submit an authorization response for the transactionvia the transaction handler 506. Authorization response includes theissuer 504, or the transaction handler 506 on behalf of the issuer 504,authorizing the transaction in connection with instructions of theissuer 504, such as through the use of business rules. The transactionhandler 506 may maintain a log or history of authorized transactions.Once authorized, the merchant 510 can record the authorization and allowthe consumer 502 to receive the good or service.

The merchant 510 may, at discrete periods, such as the end of the day,submit a list of authorized transactions to the acquirer 508, or othercomponents of the payment processing system 500, for clearing andsettling. The transaction handler 506 may compare the submittedauthorized transaction list with its own log of authorized transactions.If a match is found, the transaction handler 506 may route the clearingand settling request from the corresponding acquirer 508 to thecorresponding issuer 504 involved in each transaction. Once the acquirer508 receives the payment of the transaction from the issuer 504, it canforward the payment to the merchant 510 less any transaction costs, suchas fees.

There may be intermittent steps in the foregoing process, some of whichmay occur simultaneously. For example, the acquirer 508 can initiate theclearing and settling process, which can result in payment to theacquirer 508 for the amount of the transaction. Alternatively, or incombination, the acquirer 508 may request from the transaction handler506 that the transaction be cleared and settled.

Another Exemplary Transaction Processing System

As still further background information for the foregoing description,as will be readily understood by persons of ordinary skill in paymentsystems, now referring to FIG. 6, a transaction processing system 600 isseen. The general environment of FIG. 6 has various components thatinclude a merchant (m) 610, such as the merchant, who can conduct atransaction for goods and/or services with an account user (au) (e.g.,consumer) on an account issued to an account holder (a) 608 by an issuer(i) 604, where the processes of paying and being paid for thetransaction are coordinated by at least one transaction handler (th) 602(e.g., the transaction handler) (the components being collectivelyreferred to as “users”). The transaction includes participation fromdifferent entities that are each a component of the transactionprocessing system 600.

The transaction processing system 600 may have at least one of aplurality of transaction handlers (th) 602 that includes transactionhandler (1) 602 through transaction handler (TH) 602, where TH can be upto and greater than an eight digit integer.

The transaction processing system 600 has a plurality of merchants (m)610 that includes merchant (1) 610 through merchant (M) 610, where M canbe up to and greater than an eight digit integer. Merchant (m) 610 maybe a person or entity that sells goods and/or services. Merchant (m) 610may also be, for instance, a manufacturer, a distributor, a retailer, aload agent, a drugstore, a grocery store, a gas station, a hardwarestore, a supermarket, a boutique, a restaurant, or a doctor's office. Ina business-to-business setting, the account holder (a) 608 may be asecond merchant (m) 610 making a purchase from another merchant (m) 610.

Transaction processing system 600 includes account user (1) 608 throughaccount user (AU) 608, where AU can be as large as a ten digit integeror larger. Each account user (au) conducts a transaction with merchant(m) 610 for goods and/or services using the account that has been issuedby an issuer (i) 604 to a corresponding account holder (a) 608. Datafrom the transaction on the account is collected by the merchant (m) 610and forwarded to a corresponding acquirer (a) 606. Acquirer (a) 606forwards the data to transaction handler (th) 602 who facilitatespayment for the transaction from the account issued by the issuer (i)604 to account holder (a) 608.

Transaction processing system 600 has a plurality of acquirers (q) 606.Each acquirer (q) 606 may be assisted in processing one or moretransactions by a corresponding agent acquirer (aq) 606, where ‘q’ canbe an integer from 1 to Q, where aq can be an integer from 1 to AQ, andwhere Q and AQ can be as large as a eight digit integer or larger. Eachacquirer (q) 606 may be assisted in processing one or more transactionsby a corresponding agent acquirer (aq) 606, where ‘q’ can be an integerfrom 1 to Q, where aq can be an integer from 1 to AQ, and where Q and AQcan be as large as a eight digit integer or larger.

The transaction handler (th) 602 may process a plurality of transactionswithin the transaction processing system 600. The transaction handler(th) 602 can include one or a plurality of networks and switches (ns)602. Each network/switch (ns) 602 can be a mainframe computer in ageographic location different than each other network/switch (ns) 602,where ‘ns’ is an integer from one to NS, and where NS can be as large asa four digit integer or larger.

Dedicated communication systems 620, 622 (e.g., private communicationnetwork(s)) facilitate communication between the transaction handler(th) 602 and each issuer (i) 604 and each acquirer (a) 606. A Network612, via e-mail, the World Wide Web, cellular telephony, and/or otheroptionally public and private communications systems, can facilitatecommunications 622 a-622 e among and between each issuer (i) 604, eachacquirer (a) 606, each merchant (m) 610, each account holder (a) 608,and the transaction handler (th) 602. Alternatively and optionally, oneor more dedicated communication systems 624, 626, and 628 can facilitaterespective communications between each acquirer (a) 606 and eachmerchant (m) 610, each merchant (m) and each account holder (a) 608, andeach account holder (a) 608 and each issuer (i) 604, respectively.

The Network 612 may represent any of a variety of suitable means forexchanging data, such as: an Internet, an intranet, an extranet, a widearea network (WAN), a local area network (LAN), a virtual privatenetwork, a satellite communications network, an Automatic Teller Machine(ATM) network, an interactive television network, or any combination ofthe forgoing. Network 612 may contain either or both wired and wirelessconnections for the transmission of signals including electrical,magnetic, and a combination thereof. Examples of such connections areknown in the art and include: radio frequency connections, opticalconnections, etc. To illustrate, the connection for the transmission ofsignals may be a telephone link, a Digital Subscriber Line, or cablelink. Moreover, network 612 may utilize any of a variety ofcommunication protocols, such as Transmission Control Protocol/InternetProtocol (TCP/IP), for example. There may be multiple nodes within thenetwork 612, each of which may conduct some level of processing on thedata transmitted within the transaction processing system 600.

Users of the transaction processing system 600 may interact with oneanother or receive data about one another within the transactionprocessing system 600 using any of a variety of communication devices.The communication device may have a processing unit operativelyconnected to a display and memory such as Random Access Memory (“RAM”)and/or Read-Only Memory (“ROM”). The communication device may becombination of hardware and software that enables an input device suchas a keyboard, a mouse, a stylus and touch screen, or the like.

For example, use of the transaction processing system 600 by the accountholder (a) 608 may include the use of a portable consumer device (PCD).The PCD may be one of the communication devices, or may be used inconjunction with, or as part of, the communication device. The PCD maybe in a form factor that can be: a card (e.g., bank card, payment card,financial card, credit card, charge card, debit card, gift card, transitpass, smart card, access card, a payroll card, security card, healthcarecard, or telephone card), a tag, a wristwatch, wrist band, a key ring, afob (e.g., SPEEDPASS® commercially available from ExxonMobilCorporation), a machine readable medium containing account information,a pager, a cellular telephone, a personal digital assistant, a digitalaudio player, a computer (e.g., laptop computer), a set-top box, aportable workstation, a minicomputer, or a combination thereof. The PCDmay have near field or far field communication capabilities (e.g.,satellite communication or communication to cell sites of a cellularnetwork) for telephony or data transfer such as communication with aglobal positioning system (GPS). The PCD may support a number ofservices such as SMS for text messaging and Multimedia Messaging Service(MMS) for transfer of photographs and videos, electronic mail (email)access.

The PCD may include a computer readable medium. The computer readablemedium, such as a magnetic stripe or a memory of a chip or a chipset,may include a volatile, a non-volatile, a read only, or a programmablememory that stores data, such as an account identifier, a consumeridentifier, and/or an expiration date. The computer readable medium mayincluding executable instructions that, when executed by a computer, thecomputer will perform a method. For example, the computer readablememory may include information such as the account number or an accountholder (a) 608's name.

Examples of the PCD with memory and executable instructions include: asmart card, a personal digital assistant, a digital audio player, acellular telephone, a personal computer, or a combination thereof. Toillustrate, the PCD may be a financial card that can be used by aconsumer to conduct a contactless transaction with a merchant, where thefinancial card includes a microprocessor, a programmable memory, and atransponder (e.g., transmitter or receiver). The financial card can havenear field communication capabilities, such as by one or more radiofrequency communications such as are used in a “Blue Tooth”communication wireless protocol for exchanging data over short distancesfrom fixed and mobile devices, thereby creating personal area networks.

Merchant (m) 610 may utilize at least one POI terminal (e.g., Point ofService or browser enabled consumer cellular telephone); that cancommunicate with the account user (au) 608, the acquirer (a) 606, thetransaction handler (th) 602, or the issuer (i) 604. A Point ofInteraction (POI) can be a physical or virtual communication vehiclethat provides the opportunity, through any channel to engage with theconsumer for the purposes of providing content, messaging or othercommunication, related directly or indirectly to the facilitation orexecution of a transaction between the merchant (m) 610 and theconsumer. Examples of the POI include: a physical or virtual Point ofService (POS) terminal, the PCD of the consumer, a portable digitalassistant, a cellular telephone, paper mail, e-mail, an Internet websiterendered via a browser executing on computing device, or a combinationof the forgoing. Thus, the POI terminal is in operative communicationwith the transaction processing system 600.

The PCD may interface with the POI using a mechanism including anysuitable electrical, magnetic, or optical interfacing system such as acontactless system using radio frequency, a magnetic field recognitionsystem, or a contact system such as a magnetic stripe reader. Toillustrate, the POI may have a magnetic stripe reader that makes contactwith the magnetic stripe of a healthcare card (e.g., Flexible SavingsAccount card) of the consumer. As such, data encoded in the magneticstripe on the healthcare card of consumer read and passed to the POI atmerchant (m) 610. These data can include an account identifier of ahealthcare account. In another example, the POI may be the PCD of theconsumer, such as the cellular telephone of the consumer, where themerchant (m) 610, or an agent thereof, receives the account identifierof the consumer via a webpage of an interactive website rendered by abrowser executing on a World Wide Web (Web) enabled PCD.

Typically, a transaction begins with account user (au) 608 presentingthe portable consumer device to the merchant (m) 610 to initiate anexchange for resources (e.g., a good or service). The portable consumerdevice may be associated with an account (e.g., a credit account) ofaccount holder (a) 608 that was issued to the account holder (a) 608 byissuer (i) 604.

Merchant (m) 610 may use the POI terminal to obtain account information,such as a number of the account of the account holder (a) 608, from theportable consumer device. The portable consumer device may interfacewith the POI terminal using a mechanism including any suitableelectrical, magnetic, or optical interfacing system such as acontactless system using radio frequency or magnetic field recognitionsystem or contact system such as a magnetic stripe reader. The POIterminal sends a transaction authorization request to the issuer (i) 604of the account associated with the PCD. Alternatively, or incombination, the PCD may communicate with issuer (i) 604, transactionhandler (th) 602, or acquirer (a) 606.

Issuer (i) 604 may authorize the transaction and forward same to thetransaction handler (th) 602. Transaction handler (th) 602 may alsoclear the transaction. Authorization includes issuer (i) 604, ortransaction handler (th) 602 on behalf of issuer (i) 604, authorizingthe transaction in connection with issuer (i) 604's instructions such asthrough the use of business rules. The business rules could includeinstructions or guidelines from the transaction handler (th) 602, theaccount holder (a) 608, the merchant (m) 610, the acquirer (a) 606, theissuer (i) 604, a related financial institution, or combinationsthereof. The transaction handler (th) 602 may, but need not, maintain alog or history of authorized transactions. Once approved, the merchant(m) 610 may record the authorization, allowing the account user (au) 608to receive the good or service from merchant (m) or an agent thereof.

The merchant (m) 610 may, at discrete periods, such as the end of theday, submit a list of authorized transactions to the acquirer (a) 606 orother transaction related data for processing through the transactionprocessing system 600. The transaction handler (th) 602 may optionallycompare the submitted authorized transaction list with its own log ofauthorized transactions. The transaction handler (th) 602 may routeauthorization transaction amount requests from the corresponding theacquirer (a) 606 to the corresponding issuer (i) 604 involved in eachtransaction. Once the acquirer (a) 606 receives the payment of theauthorized transaction from the issuer (i) 604, the acquirer (a) 606 canforward the payment to the merchant (m) 610 less any transaction costs,such as fees for the processing of the transaction. If the transactioninvolves a debit or pre-paid card, the acquirer (a) 606 may choose notto wait for the issuer (i) 604 to forward the payment prior to payingmerchant (m) 610.

There may be intermittent steps in the foregoing process, some of whichmay occur simultaneously. For example, the acquirer (a) 606 can initiatethe clearing and settling process, which can result in payment to theacquirer (a) 606 for the amount of the transaction. The acquirer (a) 606may request from the transaction handler (th) 602 that the transactionbe cleared and settled. Clearing includes the exchange of financialinformation between the issuer (i) 604 and the acquirer (a) 606 andsettlement includes the exchange of funds. The transaction handler (th)602 can provide services in connection with settlement of thetransaction. The settlement of a transaction includes depositing anamount of the transaction settlement from a settlement house, such as asettlement bank, which transaction handler (th) 602 typically chooses,into a clearinghouse bank, such as a clearing bank, that acquirer (a)606 typically chooses. The issuer (i) 604 deposits the same from aclearinghouse bank, such as a clearing bank, which the issuer (i) 604typically chooses, into the settlement house. Thus, a typicaltransaction involves various entities to request, authorize, and fulfillprocessing the transaction.

The transaction processing system 600 will preferably have networkcomponents suitable for scaling the number and data payload size oftransactions that can be authorized, cleared and settled in both realtime and batch processing. These include hardware, software, dataelements, and storage network devices for the same. Examples oftransaction processing system 600 include those operated, at least inpart, by: American Express Travel Related Services Company, Inc;MasterCard International, Inc.; Discover Financial Services, Inc.; FirstData Corporation; Diners Club International, LTD; Visa Inc.; and agentsof the foregoing.

Each of the network/switch (ns) 602 can include one or more data centersfor processing transactions, where each transaction can include up to100 kilobytes of data or more. The data corresponding to the transactioncan include information about the types and quantities of goods andservices in the transaction, information about the account holder (a)608, the account user (au) 608, the merchant (m) 610, tax and incentivetreatment(s) of the goods and services, coupons, rebates, rewards,loyalty, discounts, returns, exchanges, cash-back transactions, etc.

By way of example, network/switch (ns) 602 can include one or moremainframe computers (e.g., one or more IBM mainframe computers) for oneor more server farms (e.g., one or more Sun UNIX Super servers), wherethe mainframe computers and server farms can be in diverse geographiclocations.

Each issuer (i) 604 (or agent issuer (ai) 604 thereof) and each acquirer(a) 606 (or agent acquirer (aq) 606 thereof) can use or morerouter/switch (e.g., Cisco™ routers/switches) to communicate with eachnetwork/switch (ns) 602 via dedicated communication systems.

Transaction handler (th) 602 can store information about transactionsprocessed through transaction processing system 600 in data warehousessuch as may be incorporated as part of the plurality ofnetworks/switches 602. This information can be data mined. The datamining transaction research and modeling can be used for advertising,account holder and merchant loyalty incentives and rewards, frauddetection and prediction, and to develop tools to demonstrate savingsand efficiencies made possible by use of the transaction processingsystem 600 over paying and being paid by cash, or other traditionalpayment mechanisms.

Access points 630, 632 are typically made up of small computer systemslocated at a processing center that interfaces between the center's hostcomputer and the interchange center The access point facilitates thetransmission of messages and files between the host and the interchangecenter supporting the authorization, clearing and settlement oftransaction. Telecommunication links between the acquirer (q) and itsaccess point, and between the access point and issuer (i) 104 aretypically local links within a center and use a proprietary messageformat as preferred by the center.

The VisaNet® system is an example component of the transaction handler(th) 602 in the transaction processing system 600. Presently, theVisaNet® system is operated in part by Visa Inc. As of 2006, theVisaNet® system Inc. was processing around 300 million transactiondaily, on over 1 billion accounts used in over 170 countries. Financialinstructions numbering over 16,000 connected through the VisaNet® systemto around 30 million merchants (m) 610. In 2007, around 71 billiontransactions for about 4 trillion U.S. dollars were cleared and settledthrough the VisaNet® system, some of which involved a communicationlength of around 24,000 miles in around two (2) seconds.

A data processing center (such as is located within an acquirer, issuer,or other entity) houses processing systems that support merchant andbusiness locations and maintains customer data and billing systems.Preferably, each processing center is linked to one or two interchangecenters. Processors are connected to the closest interchange, and if thenetwork experiences interruptions, the network automatically routestransactions to a secondary interchange center. Each interchange centeris also linked to all of the other interchange centers. This linkingenables processing centers to communicate with each other through one ormore interchange centers. Also, processing centers can access thenetworks of other programs through the interchange center. Further, thenetwork ensures that all links have multiple backups. The connectionfrom one point of the network to another is not usually a fixed link;instead, the interchange center chooses the best possible path at thetime of any given transmission. Rerouting around any faulty link occursautomatically.

FIG. 7 illustrates systems 740 housed within an interchange center toprovide on-line and off-line transaction processing. For dual messagetransaction, authorization system 742 provides authorization. System 742supports on-line and off-line functions, and its file includes internalsystems tables, a customer database and a merchant central file. Theon-line functions of system 742 support dual message authorizationprocessing. This processing involves routing, cardholder and cardverification and stand-in processing, and other functions such as filemaintenance. Off-line functions including reporting, billing, andgenerating recovery bulletins. Reporting includes authorization reports,exception file and advice file reports, POS reports and billing reports.A bridge from system 742 to system 746 makes it possible for membersusing system 742 to communicate with members using system 746 and accessthe SMS gateways to outside networks.

Clearing and settlement system 744 clears and settles previouslyauthorized dual message transactions. Operating six days a week on aglobal basis, system 744 collects financial and non-financialinformation and distributes reports between members It also calculatesfees, charges and settlement totals and produces reports to help withreconciliation. A bridge forms an interchange between system 744processing centers and system 846 processing centers.

Single message system 746 processes full financial transactions. System746 can also process dual message authorization and clearingtransactions, and communicates with system 742 using a bridge andaccesses outside networks as required. System 746 processes Visa, PlusInterlink and other card transactions. The SMS files comprise internalsystem tables that control system access and processing, and thecardholder database, which contains files of cardholder data used forPIN verification and stand-in processing authorization. System 746on-line functions perform real-time cardholder transaction processingand exception processing for authorization as well as full financialtransactions. System 746 also accumulates reconciliation and settlementtotals. System 746 off-line functions process settlement and fundstransfer requests and provide settlement and activities reporting.Settlement service 748 consolidates the settlement functions of system744 and 746, including Interlink, into a single service for all productsand services. Clearing continues to be performed separately by system744 and system 746.

FIG. 8 illustrates another view of components of FIG. 7 as atelecommunications network 600. Integrated payment system 750 is theprimary system for processing all on-line authorization and financialrequest transactions. System 750 reports both dual message and singlemessage processing. In both cases, settlement occurs separately. Thethree main software components are the common interface function 752,authorization system 742 and single message system 746.

Common interface function 752 determines the processing required foreach message received at an interchange center. It chooses theappropriate routing, based on the source of the message (system 742, 744or 746), the type of processing request and the processing network. Thiscomponent performs initial message editing, and, when necessary, parsesthe message and ensures that the content complies with basic messageconstruction rules. Common interface function 752 routes messages totheir system 742 or system 746 destinations.

The various steps or acts in a method or process may be performed in theorder shown, or may be performed in another order. Additionally, one ormore process or method steps may be omitted or one or more process ormethod steps may be added to the methods and processes. An additionalstep, block, or action may be added in the beginning, end, orintervening existing elements of the methods and processes. Based on thedisclosure and teachings provided herein, a person of ordinary skill inthe art will appreciate other ways and/or methods for variousimplements. Moreover, it is understood that a functional step ofdescribed methods or processes, and combinations thereof can beimplemented by computer program instructions that, when executed by aprocessor, create means for implementing the functional steps. Theinstructions may be included in computer readable medium that can beloaded onto a general purpose computer, a special purpose computer, orother programmable apparatus.

It should be understood implementations can be in the form of controllogic, in a modular or integrated manner, using software, hardware or acombination of both. The steps of a method, process, or algorithmdescribed in connection with the implementations disclosed herein may beembodied directly in hardware, in a software module executed by aprocessor, or in a combination of the two.

The various steps or acts in a method or process may be performed byhardware executing software, and in the order shown, or may be performedin another order. Additionally, one or more process or method steps maybe omitted or one or more process or method steps may be added to themethods and processes. An additional step, block, or action may be addedin the beginning, end, or intervening existing elements of the methodsand processes. Based on the disclosure and teachings provided herein, aperson of ordinary skill in the art will appreciate other ways and/ormethods for various implements.

It is understood that the examples and implementations described hereinare for illustrative purposes only and that various modifications orchanges in light thereof will be suggested to persons skilled in the artand are to be included within the spirit and purview of this applicationand scope of the appended claims.

What is claimed is:
 1. A method, comprising: storing, in a computingdevice, offer data associating an offer with a payment account of auser, the offer including a benefit applicable to a predefined purchase;receiving, in the computing device, a communication transmitted from amerchant via an acquirer of the merchant, the communication identifyingthe predefined purchase in response to the user presenting a paymentdevice associated with the payment account; in response to thecommunication received in the computing device, communicating, by thecomputing device, with an issuer of the payment account forauthorization of a payment transaction in the payment account, whereinthe payment transaction has a transaction amount that is a full price ofthe purchase less the benefit provided by the offer in accordance withthe offer data; and communicating, by the computing device, with atleast one sponsor of the offer to initiate a payment transaction from anaccount of the sponsor to the merchant for the benefit provided by theoffer to the payment transaction in the payment account of the user. 2.The method of claim 1, wherein the offer includes a rebate for thepredefined purchase of a predetermined item.
 3. The method of claim 2,wherein the communication identifies the predetermined item via productlevel data.
 4. The method of claim 3, wherein the product level dataincludes one of: a stock keeping unit, a universal product code, anidentifier of a manufacturer, a model number, a serial number, a lognumber, an international standard book number, and an identifier of acommodity.
 5. The method of claim 4, wherein the benefit is sponsored bya plurality of sponsors; and the method further comprises: debiting apredetermined portion of the benefit respectively to an account of eachof the plurality of sponsors.
 6. The method of claim 1, wherein thecommunicating with the at least one sponsor of the offer to initiate thepayment transaction is made in a batch mode for a plurality of purchasesto which the offer is applied.
 7. The method of claim 1, wherein thecommunicating with the at least one sponsor of the offer to initiate thepayment transaction is performed periodically.
 8. The method of claim 1,further comprising: detecting, by the computing device, a return of thepredefined purchase by the user; and in response to the return beingdetected, generating, by the computing device, a refund transaction fromthe merchant to the account of the sponsor.
 9. The method of claim 1,further comprising: before the communicating with the at least onesponsor of the offer to initiate the payment transaction, verifying, bythe computing device, that the benefit of the offer is applicable to thepayment transaction based at least in part on the offer data stored inthe computing device.
 10. The method of claim 9, wherein thecommunicating with the at least one sponsor of the offer to initiate thepayment transaction includes communicating to the sponsor verificationinformation for applying the benefit of the offer to the paymenttransaction.
 11. The method of claim 1, further comprising:transmitting, by the computing device, an authorization of the paymenttransaction in the payment account to the merchant via the acquirer. 12.The method of claim 11, wherein the merchant provides items purchasedvia the payment transaction in the payment account upon receiving theauthorization for the full price of the purchase less the benefitprovided by the offer.
 13. The method of claim 1, further comprising:transmitting a notification to the user about the benefit applied to thepayment transaction.
 14. A computing apparatus, comprising: atransaction handler of a payment processing network, configured to atleast: store, in a database, offer data associating an offer with apayment account of a user, the offer including a benefit applicable to apredefined purchase; receive, in the transaction handler, acommunication transmitted from a merchant via an acquirer of themerchant, the communication identifying the predefined purchase inresponse to the user presenting a payment device associated with thepayment account; in response to the communication received in thetransaction handler, communicate, by the transaction handler, with anissuer of the payment account for authorization of a payment transactionin the payment account, wherein the payment transaction has atransaction amount that is a full price of the purchase less the benefitprovided by the offer in accordance with the offer data; andcommunicate, by the transaction handler, with at least one sponsor ofthe offer to initiate a payment transaction from an account of thesponsor to the merchant for the benefit provided by the offer to thepayment transaction in the payment account of the user.
 15. Thecomputing apparatus of claim 14, wherein the benefit is sponsored by aplurality of sponsors; and the transaction handler is further configuredto: debit a predetermined portion of the benefit respectively to anaccount of each of the plurality of sponsors.
 16. The computingapparatus of claim 15, wherein the offer includes a rebate for thepredefined purchase of a predetermined item.
 17. The computing apparatusof claim 16, wherein the communication identifies the predetermined itemvia product level data.
 18. The computing apparatus of claim 14, furtherconfigured to: detect, by the computing apparatus, a return of thepredefined purchase by the user; and in response to the return beingdetected, generate, by the computing apparatus, a refund transactionfrom the merchant to the account of the sponsor.
 19. The computingapparatus of claim 14, further configured to verify that the benefit ofthe offer is applicable to the payment transaction based at least inpart on the offer data stored in the computing apparatus and communicateto the sponsor verification information for applying the benefit of theoffer to the payment transaction.
 20. A non-transitory computer storagemedium storing instructions configured to instruct a computing device toat least: store, in the computing device, offer data associating anoffer with a payment account of a user, the offer including a benefitapplicable to a predefined purchase; receive, in the computing device, acommunication transmitted from a merchant via an acquirer of themerchant, the communication identifying the predefined purchase inresponse to the user presenting a payment device associated with thepayment account; in response to the communication received in thecomputing device, communicate, by the computing device, with an issuerof the payment account for authorization of a payment transaction in thepayment account, wherein the payment transaction has a transactionamount that is a full price of the purchase less the benefit provided bythe offer in accordance with the offer data; and communicate, by thecomputing device, with at least one sponsor of the offer to initiate apayment transaction from an account of the sponsor to the merchant forthe benefit provided by the offer to the payment transaction in thepayment account of the user.